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1 PURPOSE 


This procedure establishes a system for performing testing in the Six-Degree-Of- 
Freedom Dynamic Test System (SDTS). Testing includes development and verification 
testing of customer supplied Test Articles (TAs) and other testing requirements, as 
requested. 


2 SCOPE 


This procedure applies to all SDTS testing operations and equipment. The procedure 
provides an overview of testing performed in the SDTS including test identification 
requirements, test planning and procedure development, test and performance inspection, 
test data analysis, and test report generation. 


3 ACRONYMS 


ANR 

Audit Nonconforming Records 

SR&SD 

Software, Robotics, & Simulation Division 

CB 

Crew Office 

CR 

Change Request 

DCS 

Digital Control System 

DR 

Discrepancy Report 

DSTB 

Dynamic Systems Test Branch 

DTP 

Detailed Test Procedure 

FMEA 

Failure Modes & Effects Analysis 

GSE 

Ground Support Equipment 

HA 

Hazard Analysis 

ISO 

International Organization for Standardization 

JCAR 

JSC Corrective Action Request 

JSA 

Job Safety Analysis 

JSC 

Johnson Space Center 

MOU 

Memorandum of Understanding 

MSDS 

Material Safety Data Sheet 

NASA 

National Aeronautics & Space Administration 

OIR 

Open Items Review 

QAS 

Quality Assurance Specialist 
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SDTS 

Six-Degrees-Of-Freedom Dynamic Test System 

SLP 

System Level Procedures 

SR&QA 

Safety, Reliability and Quality Assurance 

SM 

SDTS Test Manager 

TA 

Test Article 

TD 

Test Director 

TPS 

Task Perfonnance Sheet 

TR 

Test Requester 

TRE 

Test Requirement Evaluation 

TREB 

Test Requirement Evaluation Board 

TRR 

Test Readiness Review 

TRRB 

Test Readiness Review Board 

TSO 

Test Safety Officer 

WI 

Work Instructions 


4 DEFINITIONS 

Customer Agreement: the agreement formed between Software, Robotics, and 
Simulation Division (SR&SD) concerning SDTS testing services and the test requester 
(TR). This may be in any form such as a Memorandum of Understanding (MOU) as 
determined by the SR&SD Chief. 

SDTS Manager: Manager responsible for supplying the test product. The SDTS 
Manager (SM) provides technical leadership in reviewing the Test Plan, creating DTPs, 
and ensuring the successful delivery of the TR requested testing. The SM coordinates 
and communicates with the TR to define test requirements, funding, and any other related 
items in obtaining the SDTS for testing purposes. 

Six-Degree-Of-Freedom Dynamic Test System: Ground Support Equipment (GSE) 
used for testing, training, and technology development. The SDTS is a closed loop 
dynamic testing system that combines high fidelity test articles and software models to 
produce an integrated simulation of two-body contact in free space. 

Test Article: Item being tested; includes hardware, software, procedures, etc. 

Test Director: Central authority with overall responsibility for all aspects of the test. 

The test director (TD) leads the testing activity insuring procedures are carried out per 
the DTPs and SDTS Work Instructions (WIs). The SM may function as a TD when 
limited personnel are available. The TD performs the coordination of activities with the 
TR, Digital Control System Operator (DCS) and SDTS Technicians. 


Verify this is the current version before use. 








Software, Robotics, 
and Simulation Division 

Title: Testing Process 


Doc. No. SWI1.10 

Rev. C 


Date: May 2009 


6 


Testing Product: A safe and effective test which produces test data and operational 
experience that meets or exceeds the TR requirements. The results of activities or 
processes in the SDTS. The SDTS provides a testing service, support for operation of the 
SDTS, review of Test Plan, DTPs, development and expansion of capabilities, testing 
data that meets or exceeds the TR requirements, data to meet quality standards and 
demonstrations. 

Test Readiness Review: Review in which testing organization, TR, and test support 
organizations demonstrate the readiness of their equipment (including software), 
personnel, and procedures for test operations and for the risk involved in performance of 
the test. 

Test Requester: The customer requesting use of the SDTS facility. 

Test Requirements Evaluation: Evaluation in which testing organization, requester, 
and supporting organizations, as required, review the test requirements including hazards, 
the scope of work, resources required to respond to the requirements, and schedule. 

Test Safety Officer: The Quality Assurance (SR&QA) Office or JSC/NASA designated 
safety representative for the test activities. 

Test Team: The operators of SDTS equipment, the test safety representative, and the 
TD. 

Verification: Confirmation by examination and provision of objective evidence that 
specified requirements have been fulfilled. Verification concerns the process of 
examining the result of a given activity to determine conformity with the stated 
requirements for that activity. 

Validation: Validation follows successful verification. Validation concerns the process 
of examining a product to determine conformity with user needs. Validation may consist 
of calculations, analysis, simulation, inspection, and testing. Multiple validations may be 
carried out if there are different intended uses. 


5 RECORDS, REPORTS AND FORMS 

EA-004 Requirements Change Sheet 

JSC Form 90 Test Request 

JSC Form 90ACSTD Test Requirements Worksheet 
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JSC Form 1225 
JSC Form 1225a 
JSC Form 2176 
JSC Form 2176a 
SDTS Form 10.1 
STB-4 
STB-14 


Task Performance Sheet 

Task Performance Sheet-Instructions 

Discrepancy Report/Material Review Record 

Discrepancy Report/Material Review Record-Continuation Sheet 

SDTS Test Customer Survey 

Test Readiness Review Board (Approval Sheet) 

Test Procedure Deviation Sheet 


The Test Plan, DTP, and Test Report are identified by a unique document number for 
each particular test. 


Other records may also be generated in the course of SDTS testing operations such as 
design review records, “As-run” TA drawing/records, test instrumentation records, and 
test facility configuration records. 


6 REFERENCES 


EA-WI-024 

JPG 1700.1 

JPR 5335.3 

JSC SLP4.10 

SWI 1.13 

SWI 1.7 

SWI 10.1 

SWI 5.3 

SR&SD-05-001 

SVMF-OCC-F0064 

SR&SD-01-035 


General Operating Procedures Manual For EA Testing Facilities 
JSC Safety and Health Handbook 
Quality Manual 
Inspection & Testing 

Control of Non-conforming Product and Corrective Action 
Control of Customer Supplied Product 
SDTS EVA Trainer Test Rules 
SDTS DCS Operations 

Integrated Hazard Analysis for SDTS EVA Trainer 
Facility Utilization Request (FUR) 

SDTS Hazard Analysis 


7 RESPONSIBILITIES 


The TR is generally responsible for the following as agreed to in the customer agreement 
and/or Test Plan: 

a) JSC Form 90, Test Request and detailed test requirements 

b) Test Plan 

c) TA and related equipment , Interface Control Drawings and/or schematics 
including checkout, operating procedures, and handling instructions as well as 
delivery to and from SDTS 

d) Provide a technical expert who has a thorough knowledge of the TA and how 
it will respond to the test environment. 
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e) Funding 

f) TA and related equipment Failure Modes & Effects Analysis (FMEA) and 
Hazard Analyses (HA) 

g) Structural diagram of any equipment to be manufactured 

h) Completion of SDTS Test Customer Survey 

The TR is responsible for all discrepancies as well as the disposition of those 
discrepancies concerning the TA meeting test objectives or design requirements. The 
process for Control of Nonconforming product, Corrective and Preventive action, 
Inspection and Test Status concerning the TA lies solely with the TR. 

The SDTS is generally responsible for the following as agreed to in the customer 
agreement and/or Test Plan: 

a) Test Plan Support 

b) DTPs 

c) Hardware setup 

d) Facility support setup 

e) Equipment modifications 

f) Test Readiness Review (TRR) 

g) Facility operations 

h) Test verification and validation 

i) Test Report including test data 

j) Test data analysis 

k) Coordination of SR&QA support 

The SM coordinates and communicates with the TR to define test requirements, funding, 
schedule, safety, and any other related items in obtaining the SDTS for testing purposes. 
The SM assigns a TD for technical review of the request, chairs the Test Requirement 
Evaluation Board 

(TREB), provides approval to begin test operations and approves the Test Report. 

The SM interacts with the TR and provides technical leadership in reviewing the Test 
Plan, creating DTPs, and ensuring the successful and safe operation and delivery of the 
TR requested testing. 

The TD coordinates all test personnel during the safe performance of SDTS operations 
insuring procedures are carried out per the DTPs and SWIs. The TD ensures certified 
personnel are at all duty stations requiring certification during all operations. The SM 
may function as the TD when limited personnel are available. 
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The test team is responsible for the safe perfonnance of their duties in compliance with 
the SWIs and the DTPs. All test team personnel have the responsible and authority for 
calling an abort when some aspect of operation threatens the safety of the TA, test 
equipment, or test team. 

When perfonning coordinated operations, the test team will be available via the SDTS 
communication system. 


8 PROCEDURE 

8,1 Request Phase 

1. After completion of a signed customer agreement with SR&SD, the TR submits JSC 
Form 90, Test Request, to the SM. The SM logs the request in the SDTS log-book with a 
unique number. Parties shall use the unique number for all communication during all test 
phases, anomalies discovered, and in any reporting about the test. 

2. The SM forwards the TR a template Test Plan for the TR to complete. The Test Plan 
details the basic test methodology including operational considerations; test article 
description including drawings and parts lists; safety considerations; instrumentation and 
data processing requirements; facilities requirements; test schedule, constraints, 
requirements, objectives, and report requirements. 

3. The SM and TR meet as required for an initial requirement review and, if necessary, 
complete the Test Plan. During the development of the Test Plan, the SM evaluates the 
test request for feasibility. The SM evaluates the test objective, schedule, hazards and 
special test requirements for adequate definition. 

4. The SM reviews the Test Plan to re-evaluate the scope of required resources, 
availability of the test facility and hazards that relate to the test requirements. Their 
effort serves to ensure all test requirements defined in the Test Plan are clear and 
attainable. 

5. Conduct a TREB with membership consisting of the SM, TR, and others as necessary. 
The board reviews the test impacts, resources required, potential hazards, as well as 
hazards that have not been approved in previous test operations, and the proposed 
schedule. The Test Plan will serve as a quality record of this step. The TREB will make 
one of the following determinations: 

a) Approve the proposed Test Plan. The Test Plan is approved by the SM which 
provides the authority to proceed, empower resources, release of as-scoped 
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funding, pennit the project schedule to enter division schedule and start test 
preparation phase. 

b) Modify/Redefine the Test Plan after deliberation with the requester. This 
decision should be based on specific safety, performance, cost, or schedule 
requirements that can not be met or that are unclear. Once the agreed upon 
revisions are made, the SM may approve the Test Plan without holding 
another TREB. 

c) Reject the Test Plan. Again, this decision should be based on the fact that the 
required service to the TR could not be met. The SM files a copy of a memo 
describing the decision and reasons in the project files. The TR may decide to 
seek alternate approaches and submit a revised request. 

6. Following release of the Test Plan, amendments to the Test Plan and all changes 
impacting the test requirements shall be noted in the EA-004, Requirements Change 
Sheet. The form is signed by the TR and the SM to authorize implementation. Any 
changes to testing requirements that cause ‘substantial-revision’ to the test, require a new 
TREB approval. 

8.2 Test Preparation Phase and Work-site Integration 

1 . The SM serves as the point of contact, schedules test status meetings with test team, 
requesters and safety. The SM coordinates test planning and implementation of test 
requirements. Steps 2 through 5 in section 8.2 are carried out simultaneously. 

2. Arrange delivery of the TA. Once the TA is delivered, follow SWI 1.7, Control of 
Customer Supplied Product, concerning the TA. 

3. The SM in conjunction with the TD and test team write the DTP necessary to carry 
out the testing objectives outlined in the Test Plan. The DTP shall specify details 
pertaining to test execution and reference applicable SDTS procedures. It includes: 

a) Step by step TA and system operating procedures. 

b) Test configuration, including diagrams and schematics as applicable. 

c) Test conditions, constraints, and prerequisites. 

d) Provisions for quality assurance of specified steps. 

e) Abort or back-out procedures as applicable. 

f) Data acquisition and processing procedures. 

The DTP shall require concurrence from the TR, TD, SM, JSC safety representative (if 
applicable) with approval and release by SDTS SM. 
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4. The SM verifies the configuration of software and hardware for verification and 
testing. 

5. Demonstrate the test systems function as planned using approved procedures as 
applicable. The results of this step is documented in the DTP or a report, and saved as a 
quality record. Any system failure is documented in a discrepancy report (DR) per SWI 
1.13, Control of Non-conforming Product and Corrective Action. 

6. Conduct a TRR: The TRR includes the Facility Manager, SM, TD, TR, the JSC 
safety representative, and others as applicable prior to the initiation of testing to 
assure that the test preparations are adequate to meet the test objectives specified by 
the customer TR. The SM will provide the TRR the following information 
concerning the SDTS for their review: 

a) Status of TA: This includes test article receiving inspection, configuration, 
integration, condition, storage, and handling. 

b) Status of any open DRs 

c) Status of any open JSC Corrective Action Request (JCARs) and/or Audit 
Nonconforming Records (ANRs) 

d) Status of any open CRs. 

e) Status of any open Task Performance Sheets (TPSs) 

f) The current revision number of running software. If there are no software 
changes in work, then the current software revision will be defined as the 
baseline by the TRR board. If there are still software changes being made, 
then the TRR board must decide if they want to proceed with the current 
revision or wait until software modifications are complete. 

g) Results of system verification testing. 

h) Work Site setup status including pressure system certification, test 
measurement equipment calibration, camera positioning, test article, etc. 

i) Status of SDTS operator certification. 

j) Any additional infonnation which may affect the quality of the test such as 
status of SWIs and Operating Procedures. 

k) An Integrated Hazard Analysis (HA) is an identification of any open hazards. 

The TR will provide the TRR the following information concerning the TA: 

a) Status of any open DRs 

b) Status of any open JCARs and/or ANRs 

c) Status of any open CRs 

d) Status of any open TPSs 

e) The current revision number of running software. If there are no software 
changes in the works then the current software revision will be defined as the 
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baseline by the TRR board. If there are still software changes being made, 
then the TRR board must decide if they want to proceed with the current 
revision or wait until software modifications are complete. 

f) Any additional infonnation which may affect the quality. 

g) A TA HA is an identification of any open hazards. 

Special consideration will be given to assure that specified test objectives can be 
achieved and that the procedures are adequate concerning all risks involved. The TRR 
Record will document the concurrence of the TRR Chair and participants that the SDTS 
is ready to conduct testing and identify any risks associated with testing which may be 
waived or accepted by the all interested parties. Any discrepancies at the time of the 
TRR must be specifically waived by the TRR board or resolved prior to testing. The SM 
shall certify on the TRR Record that all items required to be accomplished prior to test 
initiation have been completed. The chair then verifies the final closure of the issues on 
the TRR Record. At this time, the test is approved to commence. 

8.3 Test Phase 

1. The TD initiates the test phase per the approved DTP. Testing is conducted in 
compliance with the JPG 1 700. 1 , JSC Safety and Health Handbook. 

2. Changes to the DTP made during testing require the use of STB-14, Test Procedure 
Deviation Sheets. These forms require the signature of the SM with a concurrence 
signature provided by the TR. Any revision to the DTP will be documented in the Test 
Report. 

3. Any discrepancies noted during testing concerning the SDTS equipment will be 
documented and dispositioned in a DR per SWI 1.13, Control of Non-conforming 
Product and Corrective Action. Discrepancies concerning the TA meeting test objectives 
will be documented in the test report and dispositioned by the TR per their processes. 

8.4 Post-Test Phase 

1 . TD reviews test anomalies identified during the test and verify that all have been 
documented. Make an initial detennination of the effect of the anomalies on test results. 

2. TD provides a test debriefing. An informal test debriefing for the TR and SM may be 
conducted within 30 minutes after testing has been completed. The purpose of the 
debriefing is to summarize observed results from hardware testing. 
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3. TD performs test verification. Review test results to detennine whether the test 
objectives were met. Review test data with the TR and detennine whether corrections 
are necessary. If test results or data are not satisfactory, determine whether it is 
necessary to repeat the test. TD notifies the SM and TR of test re-run and obtains 
approval using fonn STB- 14, Test Procedure Deviation Sheet. SM adjusts testing 
schedule to accommodate the test. 

4. Within two weeks after testing has been completed, a quick look will be performed by 
the SM before any documented results are released to infonn the TR of any issues or 
concerns that arose during the test series. The quick look may be conducted by phone or 
e-mail. 

5. TD performs test validation. The TD will prepare a Test Report following the 
completion of testing activities to the extent requested in the Test Plan. At a minimum, 
the Test Report contains all test data. Upon completion of the report, the TD and SM 
sign that Test Report. 

6. Whenever practical, package the TA per SWI 1.7, Control of Customer Supplied 
Product and notify the TR to remove the TA from the SDTS area. 

7. TD delivers the test report to the TR. Test Data is maintained at SDTS for one year 
after completion of the testing, or as requested by the TR. 

8. The TR signs their concurrence to the infonnation provided in the Test Report and 
returns it to the SM along with a completed SDTS Test Customer Survey. 

9. The SM approves and distributes the Test Report. The Test Report is maintained as a 
quality record of the product delivered to the TR. 

9 TEST/TRAINING READINESS REVIEW BOARD CRITERIA 

9,1 Purpose 

This procedure establishes the TRR policy for the SDTS. It defines when a formal or 
informal TRR is required; identifies the personnel and functional organization 
representation comprised by the TRRB; specifies the duties and responsibilities of the 
TRRB; and detennines the TRRB documentation requirements. 


9.2 Scope 
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This procedure is applicable to all hardware evaluations, software evaluations, tests, 
training exercises, training articles, and hardware/software modifications performed in or 
used with the SDTS located in the JSC building 9NE. 


9.3 General 


A TRR will be conducted in the SDTS to ensure readiness of the facility and/or test 
articles relative to established test requirements and objectives. The TRRB must give 
approval before conducting test/training activities using a new or revised training article 
or configuration. 

The TRRB reviews the status of the test article/payload, test facility and test 
documentation and assures they are in conformance with all applicable management 
instructions, safety standards, and test requirements. 

The Test/Training Readiness Review Board 


• Assures that the test facility and test article are ready for test/training before 
authorizing the test team to proceed. 

• Assures that all controls to mitigate risk are in place at start of test/training 
operations. 

• Assures that all critical data is adequately displayed in an easily comprehended 
graphic format. 

• Assures that adequate visual/video coverage exists to readily recognize and assess 
test problems. The degree of coverage shall be commensurate with potential risk. 

9.4 Informal TRRB 


An informal TRR may be used prior to routine test and training sessions or to review 
minor modifications completed on previously TRR payloads. The infonnal TRR consists 
of a pretest/training briefing. The pre-test/training briefing will include appropriate 
TRRB members (e.g., TD, SDTS Lead Engineer, Contractor Safety Representative, 
Contractor QAS Representative, ER/SDTS Manager, and NS/Safety Representative). 

The pretest briefing will determine that the test/training and safety procedures are in 
place, hazards are identified and understood, deviations are explicit, and hardware and 
software configurations are proper to support the test/training event. 
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Documentation requirements for the informal TRR consist of: 

• A completed TRRB Agenda/Checklist that verifies all contents of the TRR 
request have been adequately reviewed and accepted (ATTACHMENT 2). 

• A completed TRRB Approval form that signifies the test has been successfully 
reviewed and approved and the SDTS is ready to support. (ATTACHMENT 3). 

9.5 Formal TRRB 


The TRRB is responsible for examining the data presented, evaluating the issues, 
assigning action items for additional information, documentation, etc., verifying that all 
action item requirements are met and action items closed, and certifying that the 
upgraded, modified, or new facility training article, evaluation, or training exercise is 
either ready for training or acceptable for testing/training. A formal TRR must be 
conducted under the cognizance of a TRRB before the functional implementation of the 
following: 

• Addition of new hardware, software, or procedures. 

• Modification of existing SDTS hardware and/or software. 

• First-time use of new payloads and major modified payloads. 

• Activities not listed in the integrated HA. 

• An unforeseen circumstance or test/training requirement not listed in the SDTS 
integrated hazard analysis that is determined to be hazardous by NASA or contractor 
safety representatives. 

Documentation requirements for the formal TRR consist of: 

• A completed TRRB Agenda/Checklist that verifies all contents of the TRR 
request have been adequately reviewed and accepted (ATTACHMENT 2). 

• A completed TRRB Approval form that signifies the test has been successfully 
reviewed and approved and the SDTS is ready to support (ATTACHMENT 3). 

• All updated facility documentation and software rebaselines affected by the 
TRRB. 
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9.6 TRRB Preparation Phase 

Test/training status meetings shall be held for formal TRRs during the pretest phase to 
facilitate preparation of required documentation and the facility. 

An Open Items Review (OIR) will be held to identify outstanding quality control 
paperwork, whether TPSs or DRs, that may be constraints to test/training operations. 

The TD will conduct the OIR. All areas under test consideration will have the status of 
open paperwork for that area checked to determine whether it is a constraint to testing, 
not a constraint to testing or not applicable to the test/training event. 

The OIR will include the following members: 

• Test Director (chair) 

• Contractor SDTS Lead Engineer 

• Facility mechanical engineer 

• Facility electrical engineer 

• Facility software engineer 

• Contractor Safety and Quality Assurance Specialist (QAS) representative 

9.7 TRRB Member Duties and Responsibilities 

TRRB CHAIRPERSON : The TRRB Chairperson is responsible for defining the TRR 
agenda, for providing notification to all TRRB members. The TRRB chairperson is also 
responsible for completion of the TRRB Agenda/Checklist, ATTACHMENT 2 of this 
document during the TRRB. The TRRB Chairperson is responsible for the issue of 
TRRB action items and for verification of closure for Open actions assigned during the 
TRRB prior to the associated test/training event. 

TEST DIRECTOR : The TD is responsible for coordinating with the ER/SDTS Manager, 
NS/Safety Representative, Contractor Safety, Contractor Quality as well as facility 
software and hardware engineers to support Informal TRRBs. The TD is responsible for 
completion of the SDTS Pretest Checklist per SDTS SWI 5.3, SDTS DCS Operations. 
The TD is also responsible for verification of closure for Open actions assigned during 
the TRRB prior to the associated test/training event per ATTACHMENT 3. 
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FACILITY USER REPRESENTATIVE : The Facility User Representative is responsible 
for compiling the following documentation throughout the pretest/training preparation 
phase: 

• Facility Utilization Fonn (SVMF-OCC-F0064) detailing facility training 
and configuration setup requirements. 

• For providing a DTP or TPS including test/training objectives, operating 
procedures to accomplish the test, hazards and controls, equipment and 
operating limits. 

NASA TEST SAFETY OFFICER (TSOI : The NASA TSO serves as an advisor to the 
board and ensures by reviewing the associated HA and TRRB data package that proper 
controls are in place to conduct the test/training event. The safety officer approves all 
hazardous operations regarding safety issues. 

Contractor QUALITY ASSURANCE SPECIALIST REPRESENTATIVE : The QAS 
representative has the responsibility to verify that the test article and the facility are ready 
for the test by assuring that any constraining DRs or TPSs are closed. He maintains the 
official list of Open items to be addressed prior to start of test/training operations. The 
Contractor QAS representative serves as an advisor to the board and ensures all data is in 
compliance with International Organization for Standardization (ISO) Quality 
requirements. 

CONTRACTOR SDTS LEAD ENGINEER: The Contractor SDTS Lead Engineer will 
serve as the single point of contact for all test meeting activities and will perform the 
following functions related to the test/training event: 

• Assure the required documentation listed above is compiled into a package 
and distributed to TRRB members for review 3-5 working days prior to 
planned TRR. 

• Coordinate and conduct test status meeting(s) with test team personnel to 
ensure all members understand test objectives, normal and emergency 
operations, and associated hazards and controls. 

• Ensure adequate resources are available to support test/training objectives and 
schedules. 

CONTRACTOR SAFETY REPRESENTATIVE : The Contractor Safety representative 
shadows the NASA Safety representative. 
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FACILITY MANAGER REPRESENTATIVE : The Bldg 9NE facility manager 
representative supports the board as an advisor by ensuring that all planned test/training 
events are coordinated with Facility policies, overall operations, and safety guidelines. If 
the TRRB involves BNE facility modifications, the Facility Manager Representative 
coordinates the SDTS and NASA Facilities schedules. 

CONTRACTOR ENGINEERING REPRESENTATIVE : 

• The Contractor Engineering representative provides expert advice for the new 
hardware and/or payload to be used in the test/training event. Software engineers 
provide details on the software modification and explain the test data and results 
in detail 

• The Contractor Engineering representative is responsible for coordinating with 
the Contractor SDTS Safety Representative to ensure that the integrated HA 
documents those hazards unique to the installation and operation of the test 
article, procedures and/or those hazards resulting from an interaction between the 
test article and facility equipment or environment. 

• The Contractor Engineering representative is responsible for providing the Lift 
plan and/or lift procedures as well as Job Safety Analysis (JSA) (as applicable) 
for new payloads and/or new training configurations to be used in the test/training 
event. 


Verify this is the current version before use. 
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ATTACHMENT 1 


SDTS 

Session Summary Form 
Page 1 of 2 


Date: 


Instructor: 


Organization: 


SDTS Operator: 


Flight / Mission: 


Schedule Start Time: 


Session Title: 


Session Objective: 

Additional Components Used: 

O Demo / Familiarization 
O Lesson Development 
O Payload Checkout 
O Generic Training 
O Flight Specific Training 

O Payload Readiness 
O Facility Camera 
O Configuration Setup 
O Audio Communication 
O Other: 


Session Summary: 


Overall Rating (sponsor only) 

When rating your session in the SDTS, please use the following criteria: 

10: Sim performed with no problems: required support was excellent 
8-9: Minor sim problems (down time <10% of session) or support at only acceptable level 
6-7: Objectives not completed due to sim problems: objectives accomplished but sim downtime 


of >10% of session: or unacceptable support 
1-5: Session of little or no use due to sim problems (hardware or software) 


Overall Rating (sponsor 
only) 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 













Discrepancies Resulting In Loss of Time: 


Verify this is the current version before use. 
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ATTACHMENT 2 


SDTS TRR Agenda/Checklist 



Background 

Primary, Secondary Objectives (Detailed Test Plan) 

• What are test requirements? 

• What training procedures are to be utilized? 

• What is test setup requirement? 

• How will requirement be met/used? 

• What is the purpose of change (performance, maintenance, safety, etc)? 


Test Matrix, Test Procedure Review (Detailed Test Plan) 

• Are test procedures and objectives clearly defined? 

Test Article Readiness 

Payload Specific Hazard Analysis (Structural Analysis, Weld Certs, Weld Inspections, Fastener Certs, as 
required) 

• Has the hardware been inspected visually and by hand? 

• Are there sharp edges or pinch points, is structure is sound? 

• Obtain all possible record/certification information being used in the facility. 

• Ensure that all pinch points, keep out zones, or potential hazardous user interfaces are clearly labeled 


Lifting Diagram & Lift Plan Procedure 

• Verify that all lift points have been torqued to mfg. specifications and are identified 

• Discuss lifting and handling procedures in/around Bldg 9. 

• Verify signature approval for Lift Plan and Procedures. 

• Discuss structural analysis and delivery of full documentation of structural analysis 

• Discuss records of certificate of compliance for: bolts, casters, welding inspections, and lifting 
hardware 

• Were labeling requirements satisfied? 

• Discuss Payload Hazard Analysis and delivery of full documentation of hazard analysis for payload or 
hardware 

• What are hazards resulting from an interaction between a payload and facility equipment or 
environment? 


Verify this is the current version before use. 
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Facility & Support Systems Readiness 

Test Setup Readiness 

• What is combination of previously approved TRR hardware to be used in support of this TRR event? 

• Verification that SDTS personnel and user functions of payload are safe. 

• Verification that a JSA been performed for test buildup requirements. 

• Verification and review of configuration setup checklist, (what are camera requirements, lighting 
requirements, secured doors, signs posted, test in progress, implementation of exclusion zone. 

• Are all facility subsystems (Audio comm., CCTV, HPS, DCS, load cells, Control systems, motion 
table, actuators, etc) performing nominally? 


Pretest Functional Checkout 

• Verification of Software checkout results (if applicable for modified software). 

• Verification that Pre-test checklists are up to date (Software Version Control). 


Configuration Control & Documentation 

• Delivery of payload HA, drawings, lift diagrams, configuration setup checklist, JSA, structural 
analysis, etc 

• Updated drawings for facility hardware changes 

• Updated Software Files and verification of latest Version running on computers 

• Verification of affected updated Operations Procedures and checklists 

• TRR/CCB/CR action log tracking and closeout 


Contingency Plan 

• What is backup plan in the event of software or hardware anomaly relative to this test? 

• What is planned response of team for anomalies associated with conducting this test or training event? 


Emergency Procedures _ 

• What are applicable Emergency procedures associated with this training event or facility mod. 
Verify affected Operations Procedures have been updated? 

• Does test team clearly understand their responsibility? 

• Has HA adequately addressed potential failures of SDTS relative to payload interface, and 
hardware/software potential failures? 


Special Procedures Required 

• How will payload be transported from Bldg 9 to Bldg 29 per handling procedures in/around the Bldg.? 

• Are there any special tools required to support this TRR event? 

• Are there any special precautions associated with use of the payload? If so, specify 

Problem Tracking System 

Open Items Review 

• Are there any open items from previous TRRs or the Configuration Control Board relative to this 
training run or facility modification that constrain conducting this event? 

• What impacts are there to this training run or facility mod relative to TRR, CRs completed within the 
past 6 months? 

• Are there lessons learned (Close call, mishaps, etc) from previous SDTS events that apply to this TRR 
event? 

• How does this TRR affect the operational baseline? 


Verify this is the current version before use. 
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Constraints to Testing (Open DRs, CRs, IDRs, TPS, ARs) 

• Conduct review of all “Open” constraint Work Authorizing Documents (WADs) relative to 
conducting this training event 

Test Team & External Support Readiness 

Team Staffing & Certification 

• Are all test team members currently certified to support the event? 

• Is there adequate staffing to allow rotation in test team positions if necessary? 

• Verify certifications per Training Database 

• Is test team cognizant of all recent changes that may affect facility data? 

• Has test team been briefed on training or test event? 


Safety/Quality 

• Are there comments from Safety/Quality that would be constraints to this event? 

• Does the Integrated Hazard Analysis include the controls for the payload, facility, hardware/software 
modification? 

• Are the hazards adequately addressed and proper controls in place? 

• Are controls sufficient? 


Other (Center Operations, etc) 

• Does this event require NASA rigging support? 

• Are there planned power shutdowns within the timeframe of the event? 


Test Schedule 

• When is the test planned/date, duration? 

• Is there sufficient time to work off open action items in support of planned schedules? 

TRRB - Approvals 

Action Items Assigned 

• Verify that actions are clearly documented/recorded, understood and assigned for closure. 

• Does a TRR action assignment affect Test Schedule? 


Board Member Approvals 

• TRRB approves or rejects TRR. If approved and follow-on actions have been assigned, the TD and 
NASA/ER Manager verify assigned actions are complete prior to utilization of the tested product, 
modification, or procedure. 


Verify this is the current version before use. 
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ATTACHMENT 3 

TEST READINESS REVIEW BOARD APPROVAL 

Page 1 of 2 Date: 

Test Title: 

TRRB Type: (Formal) (Informal *) 

*Denotes those signatures required for Informal TRRB 

Approvals 

The SDTS Test Readiness Review Board approves conduct of this test/training upon completion 
of the listed open items prior to start of test. 

NASA/Dynamic Test Systems Branch Chief (Chair)* 

NASA/ER SDTS Manager 

Contractor Lead Engineer* 

SDTS Test Director* 

NASA Safety Representative/NS* 

NASA Software Safety/NC (As Required) 

Contractor Quality Representative/ESCG* 

Facility User Representative 

Contractor Safety Representative/ESCG* 

Bldg 9 Facility Manager (Alt. B9NE) 


Only personnel participating in the review are authorized to sign this statement. A blank signature line requires an 
“N/A”. 


Verify this is the current version before use. 
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OPEN ACTIONS 


Page 2 of 2 Date: 

Test Title: 


TRRB Type: (Formal) (Informal *) 


Action 

No. 

Action Description 

Assignee 

Date 

Closed 


















































2. OPEN ITEMS CLOSURE APPROVALS 
TEST DIRECTOR SDTS TRRB CHAIRPERSON 


Verify this is the current version before use. 











